Search for: All records

Objectives. Physical computing systems are increasingly being integrated into secondary school science and STEM instruction, yet little is known about how teachers, especially those with little background and experience in computing, help students during the inevitable debugging moments that arise. In this article, we describe a framework, comprising two dimensions, for characterizing how teachers support students as they debug a physical computing system called the Data Sensor Hub (DASH). The DASH enables students to program sensors to measure, analyze, and visualize data as they engage in science inquiry activities. Participants. Five secondary school teachers implemented an inquiry-oriented instructional unit designed to introduce students to working with the DASH as a tool for scientific inquiry. Study Method. Findings drew on video analysis of the teachers’ classroom implementations of the unit. A review of the data corpus led to the selection of 23 moments where the teachers supported an individual or small groups of students engaged in debugging. These moments were analyzed using a grounded perspective based on Interaction Analysis to characterize the teachers’ varied interactional approaches. Findings. Our analysis revealed how teachers’ moves during debugging moments fell along two dimensions. The first dimension characterizes teachers’ positioning during the debugging interactions, ranging from a positioning for teacher understanding to a positioning for student understanding of the bug. The second dimension characterizes the inquiry orientation of the teachers’ questions and guidance, ranging from focusing on the debugging process to focusing on the product—or fixing the bug. Further, teachers’ moves often fell along different points on these dimensions given nuances in the instructional context. Conclusions. The framework offers a first step toward characterizing teachers’ debugging pedagogy as they support students during debugging moments. It also calls attention to how teachers do not necessarily need to be programming experts to effectively help students learn independent and generalizable debugging strategies. Further, it illustrates the variety of expertise that teachers can bring to debugging moments to support students learning to debug. Finally, the framework provides implications for the design of professional learning and supports for teachers as they increasingly are asked to support students in computing—and debugging—activities across a range of disciplines. 

Popular platforms for teaching physical computing like the LilyPad Arduino and Adafruit Circuit Playground have simplified programming and wiring, enabling students to quickly engineer physical computing projects. But enabling students to rapidly design and build is a double-edged sword: Students can create functioning prototypes without fully understanding the underlying principles. With limited knowledge and experience, students struggle to locate and fix bugs, or errors, in their projects. Absent appropriate debugging tools, students rely on their instructor for locating errors, or worse, turn toward destructive tactics such as tearing apart and rebuilding their project, hoping the bug fixes itself. Students need tools targeted to their ability that scaffold debugging and help them locate bugs in the mixed hardware/software environment of physical computing. I developed Circuit Check to scaffold the debugging process for students. It enables students to observe real-time sensor data and test hardware components through a novel adaptation of the traditional breakpoint for physical computing. 

Physical computing projects provide rich opportunities for students to design, construct, and program machines that can sense and interact with the environment. However, students engaging in these activities often struggle to decipher the behavior of hardware components, software, and the interaction between the two. I report on the experiences of middle school students using a software tool, Circuit Check, designed to scaffold the debugging process in physical computing systems. Through think-aloud problem-solving exercises, I found Circuit Check facilitated rich instructor-student discussions. Incorporating these preliminary observations, I discuss design considerations for physical computing tools that support productive struggles and student sense-making 

Physical computing projects provide rich opportunities for students to design, construct, and program machines that can sense and interact with the environment. However, students engaging in these activities often struggle to decipher the behavior of hardware components, software, and the interaction between the two. I report on the experiences of middle school students using a software tool, Circuit Check, designed to scaffold the debugging process in physical computing systems. Through think-aloud problem-solving exercises, I found Circuit Check facilitated rich instructor-student discussions. Incorporating these preliminary observations, I discuss design considerations for physical computing tools that support productive struggles and student sense-making 

Abstract Modern surveys of gravitational microlensing events have progressed to detecting thousands per year, and surveys are capable of probing Galactic structure, stellar evolution, lens populations, black hole physics, and the nature of dark matter. One of the key avenues for doing this is the microlensing Einstein radius crossing time ( t E ) distribution. However, systematics in individual light curves as well as oversimplistic modeling can lead to biased results. To address this, we developed a model to simultaneously handle the microlensing parallax due to Earth's motion, systematic instrumental effects, and unlensed stellar variability with a Gaussian process model. We used light curves for nearly 10,000 OGLE-III and -IV Milky Way bulge microlensing events and fit each with our model. We also developed a forward model approach to infer the t E distribution by forward modeling from the data rather than using point estimates from individual events. We find that modeling the variability in the baseline removes a source of significant bias in individual events, and the previous analyses overestimated the number of t E > 100 day events due to their oversimplistic model ignoring parallax effects. We use our fits to identify the hundreds filling a regime in the microlensing parameter space that are 50% pure of black holes. Finally, we have released the largest-ever catalog of Markov Chain Monte Carlo parameter estimates for microlensing events. 

E-textiles, which embed circuitry into textile fabrics, blend art and creative expression with engineering, making it a popular choice for STEAM classrooms [6, 12]. Currently, e-textile development relies on tools intended for traditional embedded systems, which utilize printed circuit boards and insulated wires. These tools do not translate well to e-textiles, which utilize fabric and uninsulated conductive thread. This mismatch of tools and materials can lead to an overly complicated development process for novices. In particular, rapid prototyping tools for traditional embedded systems are poorly matched for e-textile prototyping. This paper presents the ThreadBoard, a tool that supports rapid prototyping of e-textile circuits. With rapid prototyping, students can test circuit designs and identify circuitry errors prior to their sewn project. We present the design process used to iteratively create the ThreadBoard’s layout, with the goal of improving its usability for e-textile creators. 

When learning to code a student must learn both to create a program and then how to debug said program. Novices often start with print statements to help trace code execution and isolate logical errors. Eventually, they adopt advance debugger practices such as breakpoints, "stepping" through code execution, and "watching" variables as their values are updated. Unfortunately for students working with Arduino devices, there are no debugger tools built into the Arduino IDE. Instead, a student would have to move onto a professional IDE like Atmel Studio and/or acquire a hardware debugger. Except, these options have a steep learning curve and are not intended for a student who has just started to learn how to write code. I am developing an Arduino software library, called Pin Status, to assist novice programmers with debugging common logic errors and provide features specific to the e-textile microcontroller, Adafruit Circuit Playground Classic. 

High-energy cosmic rays that hit the Earth can be used to study large-scale atmospheric perturbations. After a first interaction in the upper parts of the atmosphere, cosmic rays produce a shower of particles that sample it down to the detector level. The HAWC (High-Altitude Water Cherenkov) gamma-ray observatory in Central Mexico at 4,100 m elevation detects air shower particles continuously with 300 water Cherenkov detectors with an active area of 12,500 m2. On January 15th, 2022, HAWC detected the passage of the pressure wave created by the explosion of the Hunga volcano in the Tonga islands, 9,000 km away, as an anomaly in the measured rate of shower particles. The HAWC measurements are used to determine the propagation speed of four pressure wave passages, and correlate the variations of the shower particle rates with the barometric pressure changes. The profile of the shower particle rate and atmospheric pressure variations for the first transit of the pressure wave at HAWC is compared to the pressure measurements at the Tonga island, near the volcanic explosion. By using the cosmic-ray propagation in the atmosphere as a probe for the pressure, it is possible to achieve very high time-resolution measurements. Moreover, the high-altitude data from HAWC allows to observe the shape of the pressure anomaly with less perturbations compared to sea level detectors. Given the particular location and the detection method of HAWC, our high-altitude data provides valuable information that contributes to fully characterize this once-in-a-century phenomenon.